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(54) A system and method for creating an object orfemed Iransadion service ttat interoperales 
with procedural transaction coonflnators 

(57) A system and method for efficiently employing 
procedural transaction managers from an object ori- 
ented transaction processing systent Implementation 
classes are introduced to bridge selected functions from 
an object oriented transaction processing system into a 
procedural system. Bridging allows both the reuse of 
existing procedural transaction managers and interoper- 
atton between procedural and object transactions sys- 
tems which eases migration to new object oriented 
systems. Intplementation classes include methods nec- 
essary to manage information necessary to use a pro- 
cedural transaction API and to manage information 
returned k>y the procedural API. 
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ReMqflhg Invgntipn 

The present invention relates to transaction processing systems including stand-atone and dtstrbuted transaction 
processing systems. More particularty. the present invention relates to the use of oomputer implemented otsjects to 
implement a transaction processing system that supports object oriented transaction processing, but also integrates 
procedural transaction coordinators. Still more particulariy, the present invention provides a system and method for 
allowing object oriented transaction processing applications to interc^rate with procedural transaction processing appli- 
cations. 

BflgjfflrQwtf fmd Rglgfed Art 

Computer implemented transaction proc^sing systems are used tor critical business tasks In a mrnber of industries. 
A transaction defines a single unit of work that must either be fully oonpleted or fully purged without actk)n. For example, 
in the case of a bank automated teller machine (ATM) from which a customer seeks to withdraw money, the actions of 
issuing the money, reducing the balance of money on hand in the machine and reducing the customer's bank balance 
must all occur or none of them must occur. Failure of one of the subordinate actions would lead to inconsistency between 
the records and actual occurrences. 

Distributed transactton processing involves a transaction that affects resources at more than one physical or k>gical 
location. In the above example, an ATM transaction affects resources managed at the local ATM device as well as bank 
k)alances managed by a bank's main computer. A distraxited transaction may not be physically distrftxited Ixit may involve 
cooperating tasks that must be oonpleted in synchrony for successful transaction corrpletion. 

The X/Open Company Umited (K/Open is a trademark of X/Open Company Ud.) has promulgated a guide that 
describes one model for implementing distributed transaction processing. The X/Ooen Guida. Difitrit^aj Transaction 
ProoessInQ Reference Mndat October. 1991. discusses the components of a distrikxited transaction syston and the 
intenrelalionships between them. The X/Open Distributed Transaction Processing Model (the DTP Model) describes 
three main components: an Application Program (AP), a Transaction Manager (TM), and one or more Resource Man- 
agers (RMs). The Application Program uses and modifies the resources oontrolled by one or more of the Resource 
Managers. The Transaction Manager Is responsible for global transactkins and coordinates the dedsion whether to 
commit or roll-t)ack the actions taken by the Resource Managers. (Commit causes the resource to be updated while 
rofl-back causes all wortc to be discarded returning the resources to the state they were in upon transaction initiation.) 
The Resource Managers manage specific resources. Resource managers may include a database management system 
(DBMS), a fQe system, or similar resource. 

Ok>ject oriented programming systems are designed to Increase the efficiency of program development by enabling 
object reuse and simplifying system maintenance through clear separation of f imction. Each object in an object oriented 
system encapsulates the data for that object and the procedures or methods for operating on that data. Encapsulation 
means that the data tor an object can be manipulated only by that object using the defined methods. Object oriented 
systems also implemem object inheritance. Inheritance allows a more specific object to be derived from a general object. 
The more specific object can Inherit" all of the data and methods of the parent object, but can override selected data 
and methods and add others to inrplement Its unique function. 

The application of object oriented technk)ues to transaction processing systems raises many new issues but offers 
opportunities to increase system effidency through the use of object oriented principles. The Ot>ject Management Qroup. 
Inc. (OMG) has established standards for interoperable object oriented systems. The overall architecture defined by 
OMG is the Common Object Request Broker Architecture (CORBA). CORBA defines the interactions between objects, 
and in particular, between distrOxited objects in drffererrt computer systems. OMG has accepted submission of a proposal 
to standardize transaction processing in object oriented systems. This submission, entitled the Object Transaction Serv- 
jgg (OTS). sets forth the requirements for object services necessary to implement a transaction processing system. The 
OTS specification uses many of the unique capabilities of object oriented systems. The OTS model, however, is designed 
to alk3w interoperat>tlity with the X/Open DTP model and with existing procedural transaction processing systems through 
implementation of a mapping of the two-phase commit functions. 

The proposed OMG Object Transaction Service describes mapping of the object oriented interfaces to existing 
X/Open DTP interfaces. This mapping is aD that is specified in the OMG submission. The overall problem that exists is 
to define the methods required to give isolation to the application program interfaces and then to build the actual metliods. 
The f ^ problem within this overall problem is to define the methods necessary to allow dbiecX oriented transactional 
requests to interoperate with procedural transactional requests. These methods must allow for and support coordinatfon 
of two-phase commit protocols between the OMG Object Transaction Service model and the X/Open DTP model. The 
mapping is between OMG functions (such as demarcation, propagation. Involvement, and coordination) and procedural 
transaction manager functions (such as the formal two-phase commit protocols, transaction identrf iers. directory/tocation 
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management and transaction states). This coordination must occur within the transaction service and l>e isolated from 
the user interface level. 

A second problem is provision of a mechanism to allow transactional object oriented application program requests 
to effectively exist wHh transactional procedural application program requests in a single atomic transaction. In particular, 
there is a need to develop an object based approach that provides the object-oriented application interfaces while also 
providing access to procedural transaction services without requiring changes to the procedural operations within the 
application program. 

An additional problem is provision of an obfect based stmcture that is flexible enough to allow different procedural 
transaction managers to t>e plugged into the ot)ject oriented system without changing the overall object structure. Having 
tfits structure would allow the OMG Object Transaction Service interfaces to the client applications. Object Request 
Brokers, and resources (Resource Managers) to be preserved and also to preserve the classes that implement the 
function defined in the OMG GTS class specfflcations. 

Thetechnical problem theretbre enssstodevelop aset of object oriened classy 
applications to procedural transaction managers without nxxlifying either the procedural iFEmsaction manager or existing 
procedural applications. 

gymmary of the tnvwtipn 

The present invention is directed to a system and method for implementing an otsject transaction service that sup- 
ports all OMG ot>iect oriented OTS applicata'on interlaces and provides transparent access to existing procedural trans- 
action managers. 

The changes required fbr differing procedural transaction managers are encapsulated within the implementation 
classes described in this invention. These implementation classes provide the bridge between the object environment 
and the existing procedural environments. 

The present invention is directed to an object orierrted computer system for transaction processing comprising: 
means fbr receiving a message to perform a transaction service operation; routing means for routing the message to 
an object method for perfbrming the procedural transaction service; and implementation class means for enabling 
processing of the transaction service operation in response to the message. The system further includes means fbr 
receiving a result of the processing; and means fbr nxxlifying ot>j6ct data based on the result. 

The presem Invention is directed to an object structure that indid^ implementation classes to link the functions 
defined for the object oriented OMG OTS environment and existing procedural transaction managers running in existing 
environments. These classes provkle a replaceat)le bridge between the OMG t>ased classes and the actual procedural 
code running on a system. Implementation classes respond to messages generated by an OMG OTS compliant object 
and translate these messages imo the procedural calls necessary to accomplish the required action using a procedural 
transaction manager as necessary. The implementation classes also receive results informatton from the procedural 
transaction manager and use that information to update OTS based objects in the system. 

It Is therefore an object of the present invention to provUe a system that includes ot)jects specHkally structured and 
linked to bridge an object oriented transaction system to a procedural transaction system. 

It is yet another object of the invention to provide a process tor periorming transactions using object oriented appli- 
cation program interfaces to affect an underiying procedural transaction manager. 

It is yet another object of the invention to provide an object structure ttiat alk}W8 different existing procedural trans- 
action managers to be plugged In as the core transaction manager without requiring changes to the OTS classes that 
provkle tiie OMG specified interfaces and behaviours. 

Brief Description of the Drawing 

The invention wiD now be described, byway of example ohiy, with reference to the accompanying drawings, in which: 

Rgure 1 is a block diagram iOustrating the X^en Distributed Transaction Processing Model. 

Figure 2 is a bkx* diagram illustrating the OMG Object Transaction Services model. 

Figure 3 is a block diagram illustrating a system of distributed computers interconnected t>y networks in which the 
preferred embodiment of the present invention is applied. 

Figure 4 is a block diagram of a computer system that inplements the present invention. 

Rgure 5 is a diagram illustrating the transaction flow for interoperation between an object oriented and a procedural 
transaction environment. 
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Figure 6 is a diagram Ulustrating the relationship between object classes and procedural transaction services. 
Figure 7 is a diagram illustrating the flow of control In a transaction aooorcfing to the present invention. 
Figure d(a) and d(b) are diagrams illustrating the process flow in a transaction aocoiding to the present inventioa 
Rgure 9 is an example of the interface definition for a dass according to the present invention. 
p^aiiQd Dgscrifftion 

The X/Open Distributed Transaction Processing (DTP) model is shown generally In Fig. l. An Application Program 
102 executes and causes data or other resources to change state. Resources are managed by Resource Managers 
1 06 1 08 1 1 0. each of which can be a database management system (DBMS), file management system, communication 
Resource Managers (such as CPI-C. TxRPC, XATMI) or similar system. The Resource Managers may be distributed 
on conputer systems remote from the system executing the Application Program 102 or they may be implemented as 
separate processes within the S€une computer system. Transaction Manager 104 controls the completion of processing 
lor each particular transaction initiated by Application Program 102. Transaction Manager 104 coordinates the actions 
of the Resource Managers to ensure that all resources are in a consistent state at the end of the tremsaction. This 
coordination ensures that the transaction appears to operate atomically. i.e the transaction either changes all resources 
associated with the transaction or It changes none of them. 

The Object Transaction Services model defined by the Object Management Group is shown generally in Rg. 2. A 
distributed client/iserver (C/S) application is shown at 120. The application 120 comprises a nurrt>er of objects that 
exchange messages to accomplish the actions required by the transaction. The ol>jects present in the application include 
one or more Transactional Qients 1 22 that invoke operations of transactional objects. The object that begins a transaction 
is the transaction originator and the originator sends a message 1 38 to the Transactional Service at the beginning and 
end of a transaction. A transactional object is an object whose behaviour is affected by t>eing invoked within the scope 
of a transactk>n. A transactional object typically contains or refers to persistent data that can be modified by transacttonal 
requests. Persistent data is that data that will sunnsfe a system restart Persistent data typically resides on disk storage 
devices, non-volatile memory or simSar devices. 

Transactional objects are used to implement two types of apprication sen/ers: a transactk>nai server 124 and a 
recoverable senrer 126. A recoverable server implements protocols necessary to respond to a transactional server and 
ensure that all participants in the transaction agree on the outcome, either to comnvt the transaction or roll-back the 
transaction, and to be able to recover from failure. A recoverable object is a transactional object, but not all transactional 
objects are recoverable. Non-recoveratsle transactional objects may implement their state using some other recoverable 
object 

A recoverable otsject must participate in Transaction Service 130 protocols. Transaction Services 1 30 n^aintain cer- 
tain data defining the scope of each transaction as transaction context 1 32. A transaction context 1 32 is associated witii 
each ORB-aware thread (Object Request Broker (ORB) characteristics are defined by the OMQ OORBA architecture.) 
The transaction context 132 is submitted with each request generated from tiie client applteation and is used to define 
operational environment characteristics where the request is processed. Contents of the transaction context 132 can 
include a reference to the transaction coordinator, ancestor references for nested transactions, a gk)bally unique trans- 
action Id for the transaction coordinator and Implementation spedfic data understood by the sutxxdinate transaction 
coordinator. 

Recoverable ot)jects participate in Transactional Services 130 by registering a Resource 128 with the Transaction 
Service. The Transaction Service 1 30 drives the commit protocol (the two phase commit) by contacting those resources 
registered for a transaction. 

A transactional server 124 is a collection of one or more objects whose behaviour is affected by the transaction but 
have no recoversikDle states of their own. A transactional server implements transactional changes using other recoverable 
ot^ects. A transactional server does not participate in the completion of the trar«action but can force the transactk>n to 
1^ roiled back t>y sending a roll back message 140. 

A recoveratsle server 126 is a collection of objects, at least one of which is recoverable. A recoverable server par- 
ticipates in the protocols by registering one or more Resource objects 128 with the Transactk>n Service using a Regis- 
tration message 142. The Transaction Service drives the commit protocol by issuing requests 144 to the resources 
registered for a transaction. 

An example of a distributed processing system according to the present invention is shown generally in Rg. 3. 
Several computer systems are interconnecting using communication networks. For example, systems 212 and 204 are 
connected by network21 0. Systems 204. 202. and 206 by network 208. Systems 206. 216, 218, 220. and 222 by network 
214 and systems 222. 226. and 228 by networtc 224. The networks can be ariy known tocal area network (LAN) or wkle 
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area network (WAN), including token ring, Ethernet or other network. The "network" can also t>e the communication bus 
t^etween multiple processes in a single contputer system. 

A typical computer system is shown in Fig. 4. Each system 250 contains one or more central processing units 252. 
votatae memory 254. and Input/output controller 256. The input/output controller 256 manages writing to magnetic or 

5 optical disk storage 262. removat)le storage 258. 260 and to display 268, keyt)oard 266 and pointing device 264. System 
communication controller 270 manages oomnrunications with a network via communication link 272. This conf iguration 
is provided for exemplary purposes only and is not intended to be limiting. A oommeidaUy available computer system 
such as the IBM PS/2 computer or IBM RISC System/6000 workstation are examples of tfie types of systems on which 
the invention may be practised. (PS/2 and RISC system/6000 are trademarks of the IBM Corporation.) As disctssed 

10 above, the systems of a distributed environment may all be iinl^ via a single oommunicalions bus sharing memory and 
di^ storage. 

Computer system 250 is controlled by an operating system such as the OS/2 operating system, or the AIX operating 
system (OS/2 and AIX are trademarks of the IBM Corporation.) Network communications may be managed kiy a network 
operating system such as Novell Netware operating system, or the IBM LAN Server operating system. 
75 The present invention is practised using a program or suitable hardware to control a computer system such as those 
desaibed atxve. 

An object oriented application 120 performs transaction operations using the objects arKi classes defined by the 
OMG Object Transaction Services model. These classes provide an object oriented interface or API into the OMQ OTS. 
The present invention solves the problem of efficiently accessing a procedural transaction manager by building an object 

so transaction service around an existing procedural transaction coordinator. 

This approach allows higher level classes to be used to provide a consistent object oriented interface to applicatior^ 
and to provide the capability to coordinate the overall atomic transaction. At the same time, it allows different urxJeriying 
procedural transaction coordinators to be inserted into the final object transaction service. Examples of procedural trans- 
action managers include Endna TRAN. the OS/400 Transaction manager, Tuxedo. TopEnd. CICS/ESA. The present 

25 invention can be implemented with any d^ined transaction manager and is not limrted to those listed. 

An example of interoperation according to the present invention is iBustrated in Fig. 5. Fig. 5 illustrates interoperation 
between an OMG OTS and an Endna procedural transaction environment. The client application 330 invokes the obiect 
transaction services (OTS) through OMO defined object oriented interfaces. OTS 332 provides transaction services 
including propagating the transaction to the server using the OMG defined Object Request Broker (ORB) interfaces. 

30 Server OTS 334 involves a recoverable object 336 in the transaction as required and accesses an Endna procedural 
transaction manager (TRAN) 340 to synchronise transaction state information. As illustrated in the figure, the Encina 
procedural interface. TRAN, Is imk>edded in k>oth the client and server OTS 340 342. The details of how the procedural 
interlace is embedded are set forth below. Within the dient application 120. procedural transaction requests (Endna 
requests in this example) can be made. The requests use the API provided through the TRAN remote procedure call 

S5 interlace (TRPC) 344. A common TRAN 342 is accessed to manage the procedural transaction request which is sent 
to the TRAN 340 on the server. The request is processed by the existing Resource Manager (RM) 338. 

At points involving transaction state changes assodated with the two-phase commit protocol, the procedural trans- 
action managers (TRAN In this case 340 342) synchronize the transaction to ensure atomic actions aaoss bolh object 
and procedural resources involved in the transaction. 

40 The presem invention introduces a novel set of Implementation objects" to aDow use of a procedural transaction 
manager from within the ok^ect oriemed Object TVansacfion Services. The relationship of Implementation dasses to 
other transaction services is shown in Rg. 6. An object oriented application 120. as discussed above, accesses OMQ 
Ot)iect Transaction Services through an object oriented API 350. This API is. in fact, the API specified t}y OMQ for the 
Ot>iect Transaction Service arxi is provided and implemented by the OMQ defined dasses 352. Implementation dasses 

45 354 are provided t>y the present invention to t>ridge OMG classes 352 to procedural transaction services 358. The 
implementation dasses 354 have defined objed oriented imerfaces 356 that are used by the OMG dasses 352. Imple- 
mentation dasses 354 communicate through a procedural API 360 to procedural transaction services 358. This novel 
inplementation preserves the standard OMG interface and. more importantiy. the OMG class implementations. The 
OMG defined dasses need not be nK)dif ied to interad with different procedural transaction services. The implementation 

so dasses 354, on the other hand, encapsulate the deject to procedural interface in a generalized manner that can l>e 
readily adapted to different procedural transadion managers. 

Objects in an objed oriented software system perform operations on objed data using objed methods. An operation 
is requested by sending a message to a selected object requesting performance of a method. For example, the OMQ 
OTS specifies that a new transaction is started by sending a BEGINQ message to the CURRENT dbiecX. (This is rep- 

55 resented in shorter form as: CURRENTr.BEGINQ.) Any required parameters must l^e provided witiiin the parentheses. 
This message will cause the BEG//V' method of the objed 'CURRENT to be invoked. Ihe set of objects and metiiods 
defines the object oriented interlace or API. 

An objed method can invoke other objed metiiods or can carry out a function using functional code that is essentiaOy 
procedural code. The flow of control in an objed oriented system is illustrated in Fig. 7. A message 402 is sem by an 
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application program. The object oriented system routes 404 the message to an appropriate object for method seiectton 
using known otsject oriented system techniques. The requested method is selected 406 and executed 408. The present 
invention includes the necessary procedural transaction statements in an object method. The procedural statement 
invokes a procedural API 410 requesting the necessary transaction processing. Results returned from the procedural 
call may be used to update the object's data 412 or may be included in a message 414 to another object requesting a 
change to its data or other action based on the results. This new message is routed using the message routing process 

404. 

The ability of the present invention to issue procedural transaction API calls, to receive results from those calls, and 
to pass those results on to other objects in the system enable the obiject oriented OTS environment to be kept consistent 
even through it is using procedural transactton managers. The role of the transaction manager or transaction coordinator 
is to ensifl-e ttiat all resources under its control are managed as an atomic Independertt unit The present invention 
performs tracking of resources k^y intercepting key procedural transaction functions and ipdating implementation dass 
information based on these calls. An example of updated intormatkm Is the registration of resources with the transaction 
coordinator. 

The implementation classes of the present invention therefore transform the okaject oriented AP I defined by the OMO 
OTS specification into procedural actions ttiat can be pertormed by a procedural transaction coordinator or transactfon 
manager. 

The OMQ defined classes are reproduced in TetoUe I below. 



Table I 



OMQ Classes 


Class 


Description 


Current 


Bagin. end. and obtain Iriforma^on about a trartsactron 


Factory 


Create a new transaction eUong with necessary objects 


Control 


Okitains Terminator and Coordinator for a transaction 


Terminator 


Terminate by Gonvnit or rolflKick 


Coordinator 


Coordinate resources and two phase commit processing 


RecoveryCoordinator 


Coordoiate recovery of a transactfon 


Resource 


Represents the objects participating in the transaction 


SubTransactfonAware Resource 


Subset of Resource requred for nested transactions 


Transactional Object 


Used by object to indicate it is transactional 



Implementation classes are constructed to isolate the common bridge points to procedureU APIS. The preferred 
emtxxJimem of the present invention includes a number of implementation classes, a 8ut)set of which are listed in Tabfo 
II. Differem numbers and types of classes may be employed without departing from the present invention. The nurrfoer 
and type of irrplementation classes may vary deperxling on the identified k)ridge points to the procedural APIs. 



Table II 



Implementation Classes (Subset) 


Implementation Class 


Description 


Stperiorlnfo 


CoUeds Mormatfon that maps to the superior Coordinator 


Nestinglnfo 


Trades suk)ordinate and ancestor Coordinators for nested transactions 


RegisleredResouroes 


Manage a set of Resource objects involved in a transaction 


TransactionState 


Maintain perststem state of a Coordinator 


M_TtansactionState 


Metaclass of Transa^nState 


Transaction Manager 


Manages the overall transaction using OMQ and implementation objects 
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Each of the implementation classes can be described using a standard Interface Definttion Language (lOLJ. The 
IDL describes the interface to a dass including Its methods and their arguments. An example of the TransactionManager 
dass IDL 18 provided in Fig. 9. 

An example of distributed transaction processing using the OMG and implementation classes is shown in Frgs. 8(a) 
5 and 8(b). Rg. 8(a) illustrates client side processing where client 500 sends a request to an object 502. The Transaction 
Service utilizes OMG and implementation classes such as the local instance of the TransactionManager 504 to prepare 
and track the request which is eertt to the server via ORB request 506. 

Fig. 8(b) illustrates the server side processing. The request is received by the Transaction Service and tracked t>y 
a TransactionManager instance 508 using an instance 510 of dass Coordinator 512 and instances 514 516 518 520 of 
70 the implementation classes Superiorlnfo. Nestinglnfo. RegisteredResources, and TransactionState. The request 522 is 
passed to a TransactionObject 524 for completion of request processing. The reply flows t>ack through the ORB to the 
diem object 

As prenously mentioned, the Implementation dasses provide the bridge between the object transaction service 
operations and tfie procedural transactton service. The implemenlation classes encapsulate the procedural API usage 

15 so that changing the underlying procedural transaction manager is transpeu-ent to the OMQ classes. As the different 
procedural transaction services are integrated into the OTS, the areas where the functions must bridge to each other 
must be determined. This evaluation will determine which of the implementation classes must be changed to access or 
coordinate with procedural transaction manager functions. The anplementation class changes wff) involve updating the 
procedural code within the dass to use resources associated with the procedufal transaction service. Key areas where 

so this will be done include transaction state changes assodated with beginning and ending transactions. Procedural func- 
tion calls to request distribution of prepare, commit, and rollback requests will t>e changed within the implementation 
dass. 

It was also mentioned previoudy that usage of a common procedural transaction manager aids implementation of 
irrteroperability of object oriented and procedural transaction requests. The implementation classes are where this is 

25 coordinated to ensure atomic actions across all resources assodated with the overall transadion. The implementation 
dasses involved with transaction state changes indude TransactionState and TransactionManager. (See for example, 
instances 51 0 and 508 in Rg. 8(b) .) These dasses must be changed to receive and initiate the API requests for beginning 
and ending transactions. Coordination within the implementation classes of a common procedural transaction manager 
for botti the Object Trar^dion Service arxi the Procedural Transaction Service gives the capability to have an atomic 

30 transaction that avoids the traditional gateways between transaction managers. It also preserves the integrity of the 
application program because it does not require addition of coordination oode within the program and it does not change 
existing APIs. 

Claims 

35 

1 . Acomputer implemented process for operating aproceduraltiransaction manager fromanobject oriented transaction 
processing system, the process comprising the st^ of: 

receiving an object based message to perform a transaction service from a service requester; 
routing said object t>8sed message to a first cbject from a first set of objects having a transaction mettxx) 
40 corresponding to said transaction service; 

generating an oti|ect based message to perform one or more tasks of saM transaction service; 
routirig said one or rnore object t)ased messages to one or nriore objects from a second set having 
a task transaction method corresponding to said one or more tasks; and 

executing a procedural transaction service from within said task transaction method. 

45 

2. The process of daim 1 , further oonprtsing the steps of: 

receiving a result from said procedural transaction service; and 

transmitting an object t>ased message with the resuHs of said procedural transaction to sakJ service requester. 

50 3. Theprocessof daim 1. wherein said first set of objects conform to the Object Manageinent Group Object T^ 
Services specification. 

4. Th e process of dai m 2. wherein said first set of objects conform to the Object Management GrouQ Object Transaction 
Services specification. 

55 

5. The process of dcum 2, wherein ssud procedural transaction service is an Endna transaction processing systera 

8. An object oriented system for transaction processing, the system comprising: 

means for receiving a message to perform a procedural transaction senrice; 
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routing means for routing said message to an object method for pertbrnvng said procedural transaction serv- 
ice; emd 

implementation dass means for enabling processing of said procedural transaction service in response to 
saidmessaga 

7. The system of daim 6, wherein said implementation dass means indudes means for receiving a result of said 
processing; and wherein the system further comprises: 

means for modifying object data based on said result 

8. The system of daim 6, wherein the object methods conform to the Object Management Group Ok>ject Transaction 
Services specification. 

9. The system of daim 6, wherein said procedural transaction service indudes Endna transaction processing services. 

1 0. The system of daim 6. wherein said implementation classes indude: 

a TransactionManager dass for managing the overaD transaction using OMQ Olaject Transaction Services 
and implementation objects; 

a TransactionState class for managing the persistent state of a coordinator; 

a Superiortnfo dass for cdlecting information that maps to a superior coordinator; and 

a RegisteredResources dass for managing a set of resource objects involved In a transactfon. 

11. The system of claim 7, wherein said implementation dasses indude: 

a TransactionManager dass for managing the overaH transaction using OMG Object Transaction Services 
and implementation objects: 

a TransactionState dass tor managing the persistent state of a coordinator; 

a Superiorlnfo class for cdlecting information that maps to a superior coordinator; and 

a RegisteredResource dass for managing a set of resource objects involved in a transaction. 

12. The system of daim 6, wherein said routing means indudes communication means for routing said messages 
t)etween distritxited objects. 

IX The system of daim 11, virfierein said communication means conforms to the Object Management Group Object 
Request Broker specification. 

14. A distributed transaction processing system, the system comprising: 

dient means for receiving a transaction request; 

testing means for deternrvning a transaction manager type for processing said transaction request; 
tansaction manager selection means fot invoking one of a plurality of transaction managers in response to 
the testing means; 

implementation class means for txldging information k)etween an object oriemed transaction environment 
and a procedural transaction environmem; and 

a plurality of communication means for communicating with a transaction processing server in response to 
a request from said selected transaction manager. 

1 5. The system of claim 14. wherein said client means conforms to the Objed Management Group Object Transaction 
Services specification. 

16. The system of claim 1 4. wherein said plurality of communications means indudes OSF Distributed Communications 
Environment protocols and OMG Otsject Request Broker protocols. 

17. The system of claim 14, wherein said implementation dass means indude: 

TransactionManager dass means for managing the overall transaction using OMG Object Transaction Serv- 
ices and iitipfementation objects; 

TransactionState dass means for managing the persistent state of a coordinator: 
Superiorlnfo dass means tor collecting information that maps to a superior coordinator; and 
RegisteredResource dass means for rnanaging a set of resource objects Involved in a transaction. 
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Transaclion Manager Service 



interface TransactionManager : Cooperation 
{ / / metaclass: Singletnstance 

//# Update operations 

boolean add_coordinator( mWglobalJd 

in Coordinator ax^rcf, 
in unsigned long limeouf ), 

boolean set_current( InlControUc, 

intK)oleansfeicsk ); 
lControlend_current( in boolean unstack ); 
boolean remove_ooordinator( inXIDtfd ); 

//# Query operations 

IControl get_current(); 

ICoordinator getjcurrent_coordinator( ) ; 

ICoordinator getjx)ordinator( in XID global Jd ) ; 

unsigned long numjactive( hW globaljd , 

out boolean outefevidir^ ); 

1 



FIG. 9 



17 



(19) 




ililll 




(12) 



(88) Date of putslication A3: 

2ai0.1997 Bulletin 1997/44 



Europais^es Patentamt 
European Patent Office 
Office europten des brevets (11) EP 0 707 265 A3 

EUROPEAN PATEI^ APPLICATION 

(51) inta«: Q06F9/46 



(43) 


Date of publication A2: 






17.04.1996 Bulletin1996/16 




(21) 


Application number: 95306349.2 




/oo\ 
{22) 


Uoie OT Tiling, i 




(84) 


Designated Contracting States: 


• Hoidsworttt, Simon Antony James 


DE FRGB 


Andover, Hampshire, SPIO 2NN (GB) 




• Houston, lain Stuart Caldwell 


(30) 


Priority. 11.10.1994 US 320357 


Bradford Abbas, Sherborne DT9 6SD (GB) 




• Smith, Stanley Alan 


(71) 


Applicant: intemational Business Machines 


Austin, Texas 78717 (US) 




Corporation 


(74) Representative: Moss, Robert Douglas 




Anmonk, N.Y. 10504 (US) 






IBM UnHed Kingdom Limited 


(72) 


Inventors: 


intellectual Property Department 


• 


Cobb, Edward EDis 


Hursley Parte 




Saratoga, Callfdmia 95070 (US) 


Winchester Hampshfre S021 2JN (GB) 


• 


Freund, Tbomas James 






Austin, Texas 78759 (US) 





CO 

< 

in 

CO 
CM 

1^ 



(54) A system and method for creating an oblect oriented transaction service that Interoperates 
with piooeAirai transaction coordinators 

(57) A system and method Ibr efficiently emplc^ng 
procedural transaction managers from an object ori- 
ented transaction processing system. Implementation 
classes are introduced to bridge selected functions from 
an obiect oriented transaction processing system into a 
procedural system. Bridging allows both the reuse of 
existing procedural transaction managers and interop- 
eration t>etween procedural and object transactions 
systems which eases migration to new object oriented 
systems. Implementation classes include methods nec- 
essary to manage information necessary to use a pro- 
cedural transaction API and to manage intonmation 
returned by the procedural API. 




Has 



LU 



Prim»d by Rank Xorai (UK) Busmass ServiGM 



EP0707 26SA3 



Europeaa Patent 
Office 



EUROPEAN SEARCH REPORT 



EP 95 38 6349 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Catcfoiy 



INTERNATIONAL CONFERENCE ON DISTRIBUTED 
C0HPUTIN6 SYSTEMS, ARLINGTON, TEXAS. MAY 
20 > 24. 1991. 
no. CONF. 11. 29 May 1991. INSTITUTE OF 
ELECTRICAL AND ELECTRONICS ENGINEERS, 
pages 65-72. XPeee221844 
POPOVICH S S ET AL: "AN OBJECT-BASED 
APPROACH TO IMPLEMENTING DISTRIBUTED 
CONCURRENCY CONTROL" 

* page 66, right-hand column, line 42 - 
page 68. left-hand column, line 31 * 

* page 71. left-hand column, line 1 - 
right-hand column, line 8 * 

EP e 613 083 A (SUN MICROSYSTEMS INC) 31 
August 1994 
page 3. line 45 - page 4. line 32 * 
page 7, line 1 - page 9. line 31 * 

IEEE SOFTWARE. JAN. 1991. USA. 

vol. 8. no. 1. ISSN 8749-7459. 

pages 66-73. XP992637836 

SHRIVASTAVA S K ET AL; 'An overview of 

the Arjuna distributed progranming system' 

* the whole document * 



classdicahon or the 



•17 



G86F9/46 



1-17 



1-17 



TECHNICAL FIELOS 
StJkMCUED «M.a.«) 



GB6F 




X: 
Y: 



pBtladuly ittaraM H cMkM vHk 



